Bugtraq-ers: I was asked by several to summarize to the list the answers I got when I posted the following question. The names have been removed from the respones, because several asked me to not include their names. So, I felt the safest was to not include ANY names, since direct e-mail and posting responses to the list were saved in the same mail file. My original question was: >I suspect this is old stuff to many folks out there, but it is new stuff >to me (as a result of being a victim of security through obscurity). >A site I am associated with had its filesystems mounted by some site >back East (we are on the West Coast) a few days ago. One reason for >this is because all the subdirs are exported with the line of the form >(note the lack of 'access' options): The operating system is SunOS >4.1.3, running on both Sun4 and Sun 4c platforms. There is a firewall >router, but it apparantly did not block this breakin. Apparantly they >could not write to much anything, but they apparantly tried to copy the >data, because the system became so loaded on could not even see typed >characters echo, for about 20 minutes. > >/pathname -root=host1:host2:host3 > >When I suggested changing it to the form of > >/pathname -root=host1:host2:host3,access=host1:host2,host3 > >for better access control, I was told this cannot be done because it >messes up access permissions for various users. The responses follow (many were similar, so are combined/paraphrased). - ------------------------------------------------------------------- Response one: We use the above permissions on Sun OS (4.1.x) and our Auspex (Sun file system) without problems. As I understand it, the 'access' is supposed to precede the 'root' entry. We use this on a lot of file systems to permit general access to many hosts, and root access to a few. We haven't run into any access bugs that we know of. The alternative is a world writable file system, which to me is a much more serious 'bug'! - -------------------------------------------------------------------- Response Two: Blocking port 2049 would be a good idea, as long as there's nobody at your site mounting one of the public NFS sites like wuarchive or gatekeeper. We are planning to do this eventually, although it may cause some wimpers from a few people. NFS is just too attackable. It is possible to access an NFS filesystem without going through rpc.mountd. This is why blocking 2049 is also a good idea, and why you should randomise your inodes. (If the inodes are not randomised, there are some well-known inode numbers that make it easy to 'walk' the filesystem without the help of 'mount'.) - -------------------------------------------------------------------- Response Three: You could block all packets to port 2049 on your router (or even to port 111 if you want to stop all RPC traffic) - -------------------------------------------------------------------- Response Four: Yeah we've been bitten by that before too, though fortunately not by someone outside the company. However, I don't consider this a case of "security through obscurity", but rather just plain poor sysadmin documentation on the part of Sun. The way the man page reads, it's easy to intuit that -root implies -access. They should explicitly tell you that it does not. >One point I didn't ask - but was true for the affected site: Also, our exports are mount points, not subdirs. Perhaps that has something to do with it. As far as I can tell it shouldn't. Btw, the above also works on SGI's running 4.0.5. - -------------------------------------------------------------------- Response Five: It is necessary to set NFS up with a complete access list. This should not cause any problems for legitimate users. The only known problem is the denial of root access on an NFS mounted file system. ie: when installing a package as root and the NFS mounted file system has no root access. P.S.: If you obtain information on the use of X-windowing port for NFS please pass it on. I am sure what they are refering to is someone has written rpc commands to run on port 6000. NFS uses unsecured rpc to access the data. It is not a very difdicult a program to write. - --------------------------------------------------------------------- Response Six: What we do is disable NFS mounts across our firewall router. In particular, we do not allow inbound connections to port 2049 or 4045, which are the ports that NFSD and LOCKD listen on. This works quite well, and it sounds like your firewall router does not cut these ports. In case this helps, these are the ports we cut for security, on inbound connections only: TCP: 23 telnet 69 tftp 79 finger 111 sun rpc 144 NeWS 512 rexec 513 rlogin 514 rcmd 515 lpd 517 talk UDP: 23 telnet 69 tftp 79 finger 111 sun rpc 144 NeWS 2049 NFSD 4045 LOCKD When NFS v.3 becomes more common, we will have to block ports 2049 and 4045 on TCP as well, I guess, since NFS v3 supports TCP as well as UDP. Hope this helps. Please generate a summary - I'd love to see what other people do. - --------------------------------------------------------------------------- Response Seven: How we do the above is very similar to the above, the only thing we change is the order. ie. /pathname -access=host1.domain:host2.domain,root=host1.domain:host2.domain We currently use FQDN on all hosts due to the fact that Solaris 2.x sorta forces this. - --------------------------------------------------------------------------- Response Eight: What you can do to make life a little easier on yourself is get Wietse's portmapper which features better access control and better logging. This will solve some problems of people going through the portmapper as well as help you track down other problems. This is not a total fix however as any attacker can simply hunt for the port that mountd and nfsd are on without ever talking to the portmapper. - ------------------------------------------------------------------------- Response Nine: NIS and NFS are extremely insecure and probably buggy as well. The first thing to do is check for patches from the vendor. If it's a Sun, you can get the securelib package, which contains replacements for three routines in the shared library that do permission checking. If it's not a Sun (or even if it is) you can get a replacement portmapper that does permission checking. Check out ftp.win.tue.nl:/pub/security. A couple of other good places to check out are black.ox.ac.uk, ftp.tamu.edu, and research.att.com:/dist/internet_security, archive.ohio-state.edu, and of course ftp.cert.org (be warned, these guys have old versions of security related software, so you're better off getting programs from the other sites). - ------------------------------------------------------------------------ Response Ten: I suggest you check out the Personal NetBlazer. Try sending mail to info@telebit.com. If that doesn't work then send mail to postmaster@telebit.com and ask where to send your mail. I believe the Personal NetBlazer can be had for under $2000US. It is fully capable of packet filtering. It can also act as a terminal server. ======================================================================= >I had also asked: > >I was also told that people could write a program to access NFS >filesystems using the Xwindows port (whatever porT THAT is), and >defeat all the export limitiations. The person telling me this >knows no details himself, "someone told him" apparantly, so that >tidbit is next to useless to me. And the responses generally were along the lines of: - ------------------------------------------------------------------------ Response One: I'd like to hear more about this too. I'm sort of skeptical. There may be a way (hell, probably is given the lack of X security) to snarf all sorts of data through the X server (usually port 6000, btw), but I doubt it's anything NFS specific. - ------------------------------------------------------------------------ Response Two: Don't think that is possible (Xwindows is port 7000 I think). - ------------------------------------------------------------------------ Response Three: I have no knowledge of this. Sorry. Sounds kind of bogus to me, though. If this were true, then _all_ protocols, of any kind, would seem to be vulnerabilities, and I just don't buy that. There _is_ a potential security bug in using xterm, if the xterm program is suid root, AND the xterm program has the session logging feature enabled. I've not been able to get it to work myself, but others do claim this is a problem. (You can cure this my removing the suid bit from xterm, but then xterm doesn't record sessions in utmp, so the users become "invisible". This may or may not be a "useful feature". :-) ) - ------------------------------------------------------------------------ Response Four: This sounds blatently wrong. There is a loophole that lets one bypass export limitations *in special circumstances* by going through the portmapper (portmapper will happily forward your request, replacing the vital source address information and replacing it with a local address... how to exploit is left as an exercise). sounds like they didn't do their firewalling right. A proper firewall shouldn't have passed any of the client NFS traffic [if that's what they wanted]. ====================== End Summary of all responses ======================= Thanks for all the responses and info (especially regarding ports to disable to the outside world). It pretty much underscored what I felt, that access to rpc ports should be blocked in the router or firewall system, but also its a good idea to set thing up right so it isn't TOO easy to subvert in case somehow the router/firewall gets misconfigured (which is what I think caused the original problem of the remote mount from outside). There was no consensus as to why users could not access files they had rights to if the /etc/exports file was set up properly, with both the - -access= and root= options properly specified. I was simply TOLD this was what occurred by the owner. I never saw this happen MYSELF, so I cannot speculate more on it. I have concluded the problem was due to something else and mis-diagnosed, but its the owners site, and I won't beat the issue to death - if he wishes to believe that, more power to him!! One person did mention that it MIGHT be that the permissions at the export point and the mount point differed, but that shouldn't be a problem, I wouldn't think, anyway: I commonly make mountpoints mode 0, or 700 owner root to prevent any access when the filesystem isn't mounted, since the perms that will be in effect will be whatever those are at the root of the mounted filesystem are, once mounted. That wasn't the case on this site, though, the mount points were either mode 555, 755 or 777 (they varied). Well, I tried to do what I can - that is all anybody can do!! And learned some good info in the process... Hope this summary is sufficient for those who wanted some kind of summary of the responses... Thanks again!! I will now resume lurking ... :-) - -- pat@rwing [If all fails, try: rwing!pat@ole.cdac.com] Pat Myrto - Seattle WA "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers, nationally syndicated advice columnist and Director at Handgun Control Inc.